1. Field of the Invention
The present invention relates to the field of data communications networks. More particularly, this invention relates to a method and apparatus for providing proxied authentication, authorization and accounting on demand in a data communications network.
2. The Background
ISPs (Internet Service Providers) and Telcos (telephone companies) (collectively referred to as xe2x80x9cWholesale Providersxe2x80x9d or xe2x80x9cWholesalersxe2x80x9d) typically offer wholesale Internet access and retail Internet access to their subscribers. Wholesale access is typically offered to subsidiary and specialized service providers, CLECs (Competitive Local Exchange Carriers), corporations, and Community of Interest (COI) providers. Naturally, the processing afforded customers of the wholesale variety differs from the processing afforded customers of the retail variety. Subscriber information for individual wholesale users is usually stored by those who lease data communications network access from the Wholesaler. Hence, corporations, CLECs and COI providers do not normally share their user information with the wholesale providers. The Wholesaler, however, typically also has its own retail subscribers whose user information is stored in its databases. In some cases, a particular user might have accounts with both a retail and wholesale provider. Hence, the Wholesaler must distinguish between the user""s wholesale and retail accounts and initiate different actions based upon their status or Service Level Agreements (SLAs).
See, for example, FIG. 1 where a pure retail environment has a number of network access servers (NAS1, NAS2 and NAS3) which provide data communications portals to the Wholesaler""s point of presence (PoP) on the data communications network. Each NAS is in communication with a conventional AAA (authentication, authorization and accounting) service maintained by the Wholesaler. Incoming users connect to the NASes by dialing in over the telephone network or in another conventional manner such as via DSL (digital subscriber line) access, cable, ISDN (integrated services digital network, etc.).
Traditional wholesale ISPs and Roaming Service Providers offer network access through a technique called xe2x80x9cauthentication proxying.xe2x80x9d Proxying involves the transfer of the authentication responsibility to the xe2x80x9cownerxe2x80x9d of the subscriber. Thus, if a corporation was to outsource its corporate intranet to a Wholesaler, it would give up the maintenance of its dial-up servers (i.e., the NASes). It would not, however, normally want to give up the control of or information regarding its employees. Hence, when a corporate user connects to such a Wholesaler""s network access servers, the user essentially perceives that the user is dialing into a corporate facility when the user is actually dialing into the Wholesaler""s domain and then somehow gaining admittance to the corporation""s intranet.
What really happens in that scenario is that the Wholesaler determines that the user belongs to Corporation A (CorpA) by parsing either the fully qualified domain name (xe2x80x9cFQDNxe2x80x9d) (e.g., Joe@corpa.com) supplied by the user, reading the digital number identification service identification (xe2x80x9cDNIS IDxe2x80x9d) associated with the call, reading the calling line identification (xe2x80x9cCLIDxe2x80x9d) associated with the call, or by using some other known mechanism. Using a DNIS ID, the Wholesaler looks at the telephone number (or a specific NAS in access networks other than dial-up) through which the user is connecting to the network. The DNIS ID is the telephone number of the completing station. So if a user calls in to 123-456-7890 from his number of 123-444-5555, then the Wholesaler can know which number was called, i.e., the completing station. Having determined that the user tying to gain access belongs to CorpA, the Wholesaler cannot authenticate the user by itself. As noted earlier, the user""s record is still located on CorpA""s equipment. Hence, the Wholesaler will xe2x80x9cproxyxe2x80x9d out the authentication transaction from its AAA proxy service to CorpA. An AAA service within the corporation domain then identifies the user, verifies the password, and provisions the user with appropriate authorizations. It may also receive accounting information, if desired then the AAA service at CorpA notifies the Wholesaler""s proxy service that the user is acceptable and passes along provisioning details associated with the user (such as an IP (Internet protocol) address to use or a pool identification of an IP address pool from which an IP address needs to be allocated and any other information that may be needed). The Wholesaler then grants the user access to the network based upon the reply it gets back from CorpA. This technique is called xe2x80x9cproxying.xe2x80x9d This is shown diagrammatically in FIG. 2.
To be able to perform basic proxying, the Wholesaler maintains minimal information on its proxy service 14 at its PoP. Information such as supported domain names, the IP address to which the transaction is to be sent, the port number (typically an OSI Layer 4 port number) to which the transaction is to be addressed, a shared secret between the proxy service and the remote AAA service, etc., are stored as illustrated in FIG. 3.
For example, turning now to FIG. 2, user Joe@corpa.com dials in to NAS1. A PPP (point to point protocol) session 10 is typically raised between Joe""s terminal and NAS1. An LCP (Link Control Protocol) session 12 is raised between NAS1, and Joe""s terminal. At this time the NAS1, generates an AAA authentication request using a protocol such as RADIUS (Remote Authentication Dial-In User Service) to the Wholesaler""s proxy service 14. Proxy service 14 then consults its local configuration database 16 which contains information like that outlined in FIG. 3. Proxy service 14 then makes a determination about where to send the authentication request (Access-Request in RADIUS) packet. At this time, the proxy service decides to forward the authentication request to the AAA service 18 maintained in the CorpA domain 20. The CorpA AAA 18 then consults its local database 22 and authenticates Joe@corpa.com. CorpA AAA 18 then returns an access-accept packet to proxy service 14 which, in turn, sends an access-accept packet to NAS1. Then an IPCP (Internet Protocol Control Protocol) session is raised between NAS1 and Joe""s terminal during which an IP address is returned to configure Joe""s terminal""s PPP stack completing the log-in of Joe@corpa.com.
Turning now in more detail to FIG. 3 the proxy service""s database includes a table containing for each entry a domain to be proxied to, i.e., the domain of CorpA, CorpB, etc. Associated with each domain entry is a single AAA IP address that identifies the IP address of the AAA service to use at the specified domain. Associated with each AAA IP address is an IP Layer 4 port number (or some other indicator) identifying the port number on which the domain""s AAA service is listening to authentication (such as the RADIUS protocol) requests. Finally, for each entry a shared secret is stored which is used to hash (encode and decode) the packets being sent to the domain""s AAA service.
This approach has a number of drawbacks. First, the Wholesaler is unable to load balance among a number of instances of an AAA service at the domain. This is in part because it only knows of one AAA at the domain. Second, the Wholesaler is unable to detect or respond to problems at the domain""s AAA service. Third, if the domain""s AAA service becomes unavailable, no one entering the Wholesaler and requiring the use of that domain can log-in because of the authentication and authorization service outage. Fourth, if the domain""s AAA service becomes over-used and too busy, users cannot log-in with the Wholesaler or may experience delays. Furthermore, this approach offers no practical mechanism whereby a Wholesaler can switch service components for a retail user owned by a Wholesaler based upon the Wholesaler""s Service Level Agreement (SLA) with the user.
Accordingly, it would be desirable to permit a proxying ISP to load balance among multiple instances of AAA services at a remote domain. It would also be desirable to identify problems with such AAA services as well as to empower a Wholesaler to route a user to an appropriate sub-service provider based upon the SLA. Furthermore, it would be desirable for the Wholesaler to dynamically decide, based upon heuristics, the AAA service to use. The heuristics may be based upon SLA parameters such as time of day, day of week, quality of service level, subscribed and available network bandwidth, etc. Alternatively, in the case of subscribers owned by the Wholesaler, it may also be based upon agreements between the Wholesaler and one or more retailers. This is even more important when retailers start advertising rates dynamically to Wholesalers to attract traffic on their networks.
In a first aspect of the present invention, a Wholesaler dynamically identifies one of a plurality of AAA services at a remote domain to route an access request to. The AAA service is selected based upon a set of rules applied to information which has been received dynamically from the plurality of AAA services and is indicative of load and status of the plurality of AAA services. In a second aspect of the present invention, a Wholesaler, based upon a Service Level Agreement (SLA) between the Wholesaler and a user, routes the user to one of a plurality of sub-service providers.